Вчера мы писали о новых возможностях обновленной платформы виртуализации VMware vSphere 7 Update 2, а сегодня расскажем о вышедшем одновременно с ней обновлении решения для создания отказоустойчивых кластеров хранилищ VMware vSAN 7 Update 2.

Нововведения сосредоточены в следующих областях:

Давайте посмотрим, что именно нового в vSAN 7 U2:

Улучшения масштабируемости

• HCI Mesh Compute Clusters

Теперь в дополнение к анонсированной в vSphere 7 Update 1 топологии HCI Mesh для удаленного доступа к хранилищам vSAN появилась технология HCI Mesh Compute Clusters, которая позволяет иметь вычислительный кластер vSphere/vSAN без собственных хранилищ, использующий хранилища удаленных кластеров.

Самое интересное, что эти кластеры не нуждаются в лицензиях vSAN, вы можете использовать обычные лицензии vSphere.

Также такие кластеры vSAN могут использовать политики хранилищ, в рамках которых можно получить такие сервисы, как дедупликацию / компрессию или шифрование Data-at-rest:

Также было увеличено число хостов ESXi, которые могут соединяться с удаленным датастором, до 128.

Небольшое видео о том, как создать HCI Mesh Compute Cluster:

• Улучшение файловых служб

Службы vSAN file services теперь поддерживают растянутые (stretched) кластеры и двухузловые конфигурации, что позволяет использовать их для ROBO-сценариев.

• Улучшения растянутых кластеров

Растянутые кластеры vSAN теперь обрабатывают не только различные сценарии сбоев, но и условия восстановления, которые были определены механизмом DRS до наступления события отказа. DRS будет сохранять ВМ на той же площадке до того, как данные через inter-site link (ISL) будут полностью синхронизированы после восстановления кластера, после чего начнет перемещать виртуальные машины в соответствии со своими правилами. Это повышает надежность и позволяет не загружать ISL-соединение, пока оно полностью не восстановилось.

• Технология vSAN over RDMA

В vSAN 7 Update 2 появилась поддержка технологии RDMA over Converged Ethernet version 2 (RCoEv2). Кластеры автоматически обнаруживают поддержку RDMA, при этом оборудование должно находиться в списке совместимости VMware Hardware Compatibility Guide.

• Улучшения производительности

В vSAN 7 U2 была оптимизирована работа с RAID 5/6 в плане использования CPU. Также была улучшена производительность яруса буффера. Это позволяет снизить CPU cost per I/O.

Кроме того, были сделаны оптимизации для процессоров AMD EPYC (см. тут).

Улучшения для задач AI and Developer Ready

Здесь появилось 2 основных улучшения:

• S3-совместимое объектное хранилище для задач AI/ML и приложений Cloud Native Apps.

На платформе vSAN Data Persistence platform теперь поддерживаются компоненты Cloudian HyperStore и MinIO Object Storage. Пользователи могут потреблять S3-ресурсы для своих AI/ML нагрузок без необходимости долгой настройки интеграций.

• Улучшения Cloud Native Storage в vSphere и vSAN
  

Теперь Cloud Native Storage лучше поддерживает stateful apps на платформе Kubernetes. Также vSAN предоставляет простые средства для миграции с устаревшего vSphere Cloud Provider (vCP) на Container Storage Interface (CSI). Это позволит иметь персистентные тома Kubernetes на платформе vSphere и расширять их по мере необходимости без прерывания обслуживания.

Улучшения безопасности

• Службы vSphere Native Key Provider Services

Это механизм, который позволяет использовать защиту data-at-rest, такую как vSAN Encryption, VM Encryption и vTPM прямо из коробки. Также для двухузловых конфигураций и Edge-топологий можно использовать встроенный KMS-сервис, который работает с поддержкой ESXi Key Persistence.

• Средства для изолированных окружений

VMware предоставляет Skyline Health Diagnostics tool, который позволяет самостоятельно определить состояние своего окружения в условиях изоляции от интернета. Он сканирует критические компоненты на проблемы и выдает рекомендации по их устранению со ссылками на статьи базы знаний VMware KB.

• Улучшения Data In Transit (DIT) Encryption

Здесь появилась валидация FIPS 140-2 криптографического модуля для DIT-шифрования.

Упрощение операций

• Улучшения vLCM

Для vSphere Lifecycle Manager появились следующие улучшения:

• vLCM поддерживает системы Hitachi Vantara UCP-HC и Hitachi Advanced Servers, а также серверы Dell 14G, HPE10G и Lenovo ThinkAgile.
• vLCM теперь поддерживает кластеры, которые используют vSphere with Tanzu с технологией NSX-T networking.
• При создании кластера можно указать образ существующего хоста ESXi.

• Улучшения защиты данных

При сбое и недоступности хранилищ хост ESXi, который понял, что произошла авария, начинает записывать дельта-данные с этого момента не только на хранилище, где хранится активная реплика, но и в дополнительное хранилище, чтобы обеспечить надежность данных, создаваемых во время сбоя. Ранее эта технология применялась для запланированных операций обслуживания.

• Поддержка Proactive HA

vSAN 7 Update 2 теперь поддерживает технологию Proactive HA, которая позволяет проактивно смигрировать данные машин на другой хост ESXi.

• Улучшения мониторинга

Здесь появились новые метрики и хэлсчеки, которые дают больше видимости в инфраструктуре коммутаторов, к которой подключены хосты vSAN. На физическом уровне появились дополнительные метрики, такие как CRC, carrier errors, transmit и receive errors, pauses. Также для новых метрик были добавлены health alarms, которые предупредят администратора о приближении к пороговым значениям.

• Улучшения vSphere Quick Boot

Здесь появилась техника ESXi Suspend-to-Memory, которая позволяет еще проще обновлять хосты ESXi. Она доступна в комбинации с технологией ESXi Quick Boot. Виртуальные машины просто встают на Suspend в памяти ESXi, вместо эвакуации с хоста, а потом ядро гипервизора перезапускается и хост обновляется.

Скачать VMware vSAN 7 Update 2 в составе vSphere 7 Update 2 можно по этой ссылке. Release Notes доступны тут.

Бонус-видео обзора новых фичей от Дункана Эппинга:

Компания VMware выпустила большое обновление серверной платформы виртуализации VMware vSphere 7 Update 2, включающее в себя множество новых возможностей и улучшений. Напомним, что прошлый релиз vSphere 7 Update 1 был выпущен в начале сентября прошлого года, так что времени прошло уже немало.

Нововведения второго пакета обновлений сконцентрированы в трех основных областях:

Давайте посмотрим на новые возможности vSphere 7 Update 2 более детально:

1. Инфраструктура AI и Developer Ready

На основе технологий, анонсированных в 2020 году, компании VMware и NVIDIA сделали совместный анонс платформы AI-Ready Enterprise Platform.

NVIDIA объединилась с VMware для виртуализации рабочих AI-нагрузок в VMware vSphere с помощью NVIDIA AI Enterprise. Это позволяет предприятиям разрабатывать широкий спектр решений для работы с искусственным интеллектом, таких, как расширенная диагностика в здравоохранении, умные предприятия для производства и обнаружение мошенничества в финансовых услугах.

NVIDIA предоставляет пользователям уникальный набор утилит и фреймворков для решения AI-задач на платформе VMware vSphere.

Решение AI Enterprise:

• Поддерживает последние поколения GPU от NVIDIA в целях достижения максимальной производительности (до 20 раз лучше, чем в прошлом поколении).
• Поддерживает NVIDIA GPUDirect RDMA for vGPUs.
• Поддерживает разделение NVIDIA multi-instance GPU (MIG), что позволяет обеспечивать горячую миграцию виртуальных машин c vGPU на борту c помощью vMotion.
• Посредством Distributed Resource Scheduler (DRS) обеспечивает автоматическую балансировку машин AI-инфраструктуры по хост-серверам.

Также появились и новые возможности в плане поддержки инфраструктуры контейнеров vSphere with Tanzu:

• Интегрированная балансировка нагрузки на приложения посредством VMware NSX Advanced Load Balancer Essentials edition с поддержкой HA с использованием автоматизаций Kubernetes-native (подробнее об этом тут).
• Сервисный кластер Tanzu Kubernetes Grid и Supervisor-кластер можно обновить до Kubernetes 1.19.
• Улучшенная поддержка сторонних репозиториев, что повышает гибкость и безопасность.

2. Инфраструктурные улучшения и безопасность данных

В этой категории появились следующие новые возможности:

• Новый vSphere Native Key Provider - механизм, который позволяет использовать защиту data-at-rest, такую как vSAN Encryption, VM Encryption и vTPM прямо из коробки.

• Поддержка Confidential Containers для vSphere Pods, которые используют память AMD SEV-ES и CPU data encryption на платформах AMD EPYC.
• Механизм ESXi Configuration Encryption, который использует оборудование Trusted Platform Module (TPM) для защиты ключей ESXi на хостах.
• Техника ESXi Key Persistence, которая дает возможности для защиты данных data-at-rest на изолированных хостах.
• Обновленный документ vSphere Security Configuration Guide.
• Обновленные рекомендации vSphere Product Audit Guides, а также FIPS validation для сервисов vCenter Server.

3. Упрощение операций

• Техника ESXi Suspend-to-Memory, которая позволяет еще проще обновлять хосты ESXi. Она доступна в комбинации с технологией ESXi Quick Boot. Виртуальные машины просто встают на Suspend в памяти ESXi, вместо эвакуации с хоста, а потом ядро гипервизора перезапускается и хост обновляется.
• Оптимизации процессоров AMD EPYC CPU, что приводит к улучшению производительности.
• Поддержка рабочих нагрузок Persistent Memory (PMEM) со стороны  vSphere HA. Это позволяет техникам DRS initial placement и High Availability полноценно работать в кластере.
• Новый функционал решения vSphere Lifecycle Manager with Desired Image Seeding, который позволяет автоматизировать обновление микрокода к желаемому состоянию:
  • Все фичи vSphere Lifecycle Manager теперь доступны для окружений vSphere with Tanzu.
  • Функция Desired image seeding позволяет реплицировать информацию о желаемой конфигурации с референсного хоста, экономя время администратора на настройку.
• Функция vMotion Auto Scaling, которая позволяет автоматически подстраивать производительность в сетях 25, 40 и 100 Гбит.
• Уменьшенное I/O latency и jitter для проброшенных напрямую (passthrough) сетевых адаптеров.
• Улучшенная поддержка Virtual Trusted Platform Module (vTPM) для гостевых ОС Windows и популярных дистрибутивов Linux.
• Улучшения VMware Tools, включая Guest Store - метод для распространения конфигураций и файлов между виртуальными машинами, а также драйверы Precision Clock drivers для службы Windows Time Service.
• Улучшенные vCenter Server REST API, что расширяет возможности по автоматизации операций vCenter.

Ссылки, которые могут оказаться полезными:

• Youtube-канал с новыми фичами vSphere 7 Update 2
• Технические статьи о некоторых новых возможностях
• Документация по vSphere
• Основной сайт VMware vSphere
• Release notes для ESXi 7 Update 2, а также для vCenter 7 Update 2

Скачать VMware vSphere 7 Update 2 можно по этой ссылке.

Недавно компания Veeam Software, производитель лучших решений для обеспечения доступности виртуального датацентра, выпустила обновление платформы Veeam Cloud Data Management Platform, в состав которой входит самое известное решение для защиты виртуальных сред - Veeam Backup and Replication v11. Мы уже писали об RTM-релизе этого продукта, где вкратце рассказывали его новых возможностях, а сегодня разберем их подробнее.

Итак, собственно основные новые возможности Veeam Backup and Replication v11 (наш топ-15):

1. CDP : Continuous Data Protection

Эта технология позволяет настроить непрерывную защиту виртуальных машин средствами репликации таким образом, чтобы соблюдать заданные политики RPO (Recovery Point Objectives). Достигается это за счет использования технологии VMware VAIO (vSphere API for I/O filtering).

Для этого на хосты ESXi ставится специальный VIB-пакет (фильтр VAIO), который в режиме драйвера привязывается к нужным ВМ.

При создании CDP-политики вы задаете время в секундах, за которое вы можете себе позволить потерять данные в случае сбоя (RPO):

Short-term реплики будут crash-консистентными, а long-term можно уже настроить как Application-aware, чтобы быть уверенным в работоспособности приложений виртуальной машины в конкретной точке в прошлом.

2. Функции асинхронного процессинга

В Veeam v11 при чтении данных с репозиториев происходит их асинхронный процессинг. Это ускоряет процесс для Enterprise-оборудования, но может быть неудобно для недорогих систем хранения, поэтому эту опцию можно отключить в реестре.

3. Возможность Backup Copy Retention

Политика хранения задач Backup copy job теперь имеет такую же логику, как и primary backup job - то есть GFS (Grandfather-Father-Son).

4. Улучшенная работа с тэгами vSphere

Теперь вы можете использовать оператор AND для добавления условия по комбинациям тегов при поиске и создании задач.

Теперь представление с избранными фильтрами есть в управляющем дереве наравне с самими фильтрами.

6. Защищенный Linux-репозиторий

Возможность создания на Linux-репозиториях бэкапов, которые нельзя удалить (immutability), в целях защиты от вредоносных действий, который может предпринять злоумышленник, заметая следы (также это очень полезно в борьбе с Ransomware, когда может возникнуть ситуация, что вас нет рабочих систем, а бэкапы удалены). Кроме того, это может защитить от намеренной порчи данных изнутри организации.

Подробнее об этой штуке мы писали вот тут.

7. Функция Instant MSSQL Recovery

Очень подробно об этой возможности на русском языке рассказано тут. Эта технология, по аналогии с Instant VM Recovery, позволяет быстро восстановить поврежденную или удаленную базу данных MS SQL из резервной копии. Для этого надо зайти в Restoring Application Items -> Microsoft SQL Server. Далее в Veeam Explorer для нужной базы нужно выбрать опцию Instant Recovery.

Работает сама технология по такой схеме:

Теперь вам не нужно развертывать эти виртуальные модули, чтобы иметь возможность быстро восстанавливать файлы на Linux. Бэкап можно примонтировать к любой Linux-машине напрямую. Теперь восстановление будет работать быстрее, так как не нужно тратить время на развертывание helper appliance.

Отдельные файлы можно восстанавливать также и в системах IBM AIX, MAC и Oracle Solaris.

9. Улучшенные режимы Linux Backup Proxy

Теперь можно использовать не только методику hot-add, как было в 10-й версии, но и другие режимы (Network Mode, Direct SAN с NFS, iSCSI и FC, а также бэкап из снапшотов хранилищ).

• Технология CDP Low second RPO replication, которая позволяет улучшить показатели репликации за счет использования интерфейса vSphere APIs for IO (VAIO).
• VCD to VCD Replication – функция для провайдеров VCSP, которая позволяет реплицировать данные между организациями VMware Cloud Director для одного или разных инстансов VCD.
• VCD Native HTML5 Plugin - vCloud Director Self Service Portal интегрирован напрямую в VCD.
• Улучшенная поддержка объектных хранилищ, в частности появилась поддержка Google Storage.

Новая версия консоли Veeam Service Provider Console v5 даст сервис-провайдерам следующие возможности: 

• Готовая к производственной эксплуатации третья версия API
• Новые возможности контроля над агентами для Windows, Linux и Mac
• Возможность управлять бэкапами на AWS и Azure через обновленные нативные плагины
• Улучшенные функции безопасности и новые интеграции

12. Модуль PowerShell для Veeam Backup and Replication

Теперь есть интегрированный модуль PowerShell 6.0, который устанавливается по умолчанию. Он позволяет управлять инфраструктурой резервного копирования на базе решений Veeam с помощью сценариев. Также в одиннадцатой версии Veeam B&R появилось 184 новых командлета.

13. Новый Rest API для Veeam Backup and Replication

Теперь Rest API есть не только в Veeam Backup Enterprise Manager, но и непосредственно на бэкап-серверах, что существенно увеличивает гибкость выполнения задач и построения новых интеграций через API.

14. Поддержка Amazon S3 Glacier и Microsoft Azure Archive Storage

Теперь администраторы могут использовать сервисы хранилища Amazon S3 Glacier (включая Glacier Deep Archive) и Microsoft Azure Archive Storage для обеспечения полного цикла облачного хранения резервных копий.

15. Расширение поддержки объектных хранилищ

Теперь можно использовать Google Cloud Storage (GCS) как объектное хранилище за счет нативной интеграции GCS через собственный API Veeam.

Backup & Replication v11 содержит новые версии Veeam ONE v11 (11.0.0.1379), а также апдейт Agent for Windows (5.0.0.4300) и Linux (5.0.0.4318), плюс совершенно новые Mac Agent (1.0.0.713) и Veeam Service Provider Console (5.0.0.6726). Про агенты можно подробно прочитать на русском языке вот тут.

Полный список новых возможностей приведен в документе Veeam v11 What's New (всего их более 200), в котором они занимают аж 21 страницу. Скачать новую версию этого продукта можно по этой ссылке.

Осенью прошлого года мы писали о выходе бета-версии операционной системы VMware Photon OS 4.0 Beta, использующейся в виртуальных модулях VMware (Virtual Appliances), которые реализуют различные вспомогательные сервисы. 

На днях вышла финальная версия Photon OS 4.0, давайте посмотрим, что там появилось нового:

Главные улучшения

• Ядро реального времени для приложений телекома и vRAN (Virtual Radio Network)

  Наступает эра 5G, и VMware сделала в Photon OS 4.0 возможности поддержки телеком-приложений реального времени на уровне ядра (Photon Real Time kernel). Это позволит технологиям vRAN (Virtual Radio Network) использовать возможности ОС Photon при развитии инфраструктуры 5G-операторов. Для этого появился специальный kernel flavor, который называется "linux-rt". Вместе с остальными компонентами (userspace-пакетами) этот режим называется Photon Real Time (RT).

• Безопасность
  
  Photon 4.0 получила поддержку таких технологий по обеспечению безопасности, как SELinux, Security Encrypted Virtualization – Encrypted Status и Intel Software Guard Extensions. Обязательная система контроля доступа, прошитая на уровне ядра, позволяет SELinux дать администраторам гранулярный и гибкий доступ к ресурсам. Также Photon OS позволяет из коробки, на уровне политик, обеспечить нужды приложений в изоляции. Также поддерживается SELinux для контейнеров, что было протестировано для docker, containerd и runc.
  
  Поддержка драйверов Intel SGX drivers позволяет приложениям использовать ресурсы CPU для создания "анклавов" - полностью защищенных модулей исполнения, недоступных на аппаратном уровне другим процессам.
  

• Обновленный механизм сетевой конфигурации
  
  Теперь Photon 4.0 имеет полностью переработанную библиотеку network configuration management library вместо netmgr, которая предоставляет API для большинства задач конфигурации (IP-адреса, маршруты, DNS и прочее). То есть вместо файлов конфигурации можно использовать API.

• Оптимизации производительности для решения vSphere with Tanzu
  
  Исторически Photon ОС имела специальный контекст ядра linux-esx, который был специальным образом оптимизирован для работе на платформе VMware ESXi точки зрения производительности и предоставляемых возможностей. В Photon 4.0 то же самое появилось и для контейнерной среды исполнения vSphere with Tanzu, например, уменьшение времени запуска для контейнеров и приложений.

• Прочие улучшения
  
  - Поддержка Raspberry Pi 4
  - Для ARM-архитектуры доступны образы в формате OVA и AMI
  - В tdnf добавлена поддержка расширенной конфигурации сервисов безопасности
  - Ядро обновлено до версии 5.10 (декабрь 2020)

Установщик и обновления

• Поддержка распределенных билдов с использованием Kubernetes
• Доступность установщика Photon OS в виде RPM-пакета
• Поддержка нескольких дисков в image builder
• Поддержка самоподписанных SSL-сертификатов в kickstart-установке из ISO-образа
• Для RPM используется механизм zstd по умолчанию

Состав пакета

• Готовые образы для облачного развертывания в Microsoft Azure (новое), Google Compute Engine (GCE), Amazon Elastic Compute Cloud (EC2) и продуктах VMware (vSphere, Fusion и Workstation)
• Критические обновления следующих пакетов:
• Linux kernel 5.10 LTS
• Glibc 2.32
• systemd 247
• Python3 3.9
• Openjdk : 1.8.0.265, 11.0.9
• Openssl : 1.1.1
• Cloud-init: 20.4.1
• GCC: 10.2.0
• Обновленные версии основных пакетов, доступные в репозиториях

Скачать VMware Photon OS 4.0 в виде OVA-пакета или ISO-образа можно по этой ссылке.

Продолжаем рассказывать о лучшем в отрасли решении для создания программных хранилищ под виртуальные машины на базе хост-серверов ESXi - StarWind Virtual SAN for vSphere. Как многие знают, с какого-то момента StarWind стала поставлять свое решение для платформ VMware в виде виртуального модуля (Virtual Appliance) на базе Linux, который реализует основные сервисы хранения, дедупликации и компрессии, а также отказоустойчивости и обеспечения надежности данных в виртуальных машинах.

Для виртуального модуля StarWind работа механизма дедупликации и компрессии обеспечивается средствами Linux-движка Virtual Data Optimizer (VDO), который появился относительно недавно. Это удобный и надежный способ экономии дискового пространства за счет использования дополнительных емкостей оперативной памяти на хосте.

Для начала вам нужно определиться с оборудованием хостов ESXi, где вы будете развертывать виртуальные модули StarWind. Как вы понимаете, в целях обеспечения отказоустойчивости таких узлов должно быть как минимум два.

Что касается HDD и SSD-дисков, то нужно также спланировать конфигурацию RAID на хранилище хостов. Сделать это можно в соответствии с рекомендациями, описанными в базе знаний StarWind. Вы можете использовать программный или аппаратный RAID, о настройках которого мы расскажем ниже.

Что касается дополнительной оперативной памяти на хосте ESXi, то нужно выбирать ее объем, исходя из следующих критериев:

• 370 МБ плюс дополнительные 268 МБ на каждый 1 ТБ физического хранилища
• Дополнительно 250 МБ на 1 ТБ физического хранилища, если включена дедупликация (UDS index)

То есть для 4 ТБ физического хранилища с дедупликацией вам понадобится:

370 MB + 4 * 268 MB +4 * 250 MB = 2 442 MB RAM

Итого 2,4 ГБ оперативной памяти дополнительно к памяти под ОС виртуального модуля. Вообще, StarWind рекомендует 8 ГБ памяти для виртуального модуля - 4 ГБ на машину и 4 ГБ на движок VDO для работы с хранилищем.

Один VDO-том может работать с хранилищем до 256 ТБ, что покрывает максимум потребностей в рамках хранилищ на базе серверов. Также StarWind очень рекомендует использовать дисковые массивы All-flash или NVMe-оборудование.

Общее правило развертывания таких хранилищ таково:

• Под VDO: аппаратный или программный RAID (LVM или mdraid)
• Над VDO: "толстые" (thick) диски StarWind Virtual SAN в режиме stand-alone или HA

Надо понимать, что сам том VDO - это тонкий диск, растущий по мере наполнения, поэтому устройство под ним должно иметь расширяемую природу (MD RAID, LVM).

Примерная схема отказоустойчивого решения StarWind Virtual SAN for vSphere на базе 2 узлов выглядит так:

После того, как вы установите StarWind Virtual SAN, настроите виртуальную машину и StarWind Management Console, нужно будет настроить аппаратный или программный RAID для хранилища.

Если вы используете аппаратный RAID, то просто создайте виртуальный диск для ВМ StarWind Virtual SAN на его хранилище, но обязательно типа "Thick Provisioned Eager Zeroed" (также вы можете использовать RDM-диск):

Если же вы будете использовать программный RAID, то нужно будет использовать HBA или RAID-контроллер в режиме DirectPath I/O passthrough, чтобы получить прямой доступ к дискам и собрать на их базе RAID-массив.

Для этого вам нужно будте выбрать правильный HBA/RAID-контроллер как PCI-устройство:

И пробросить его напрямую в виртуальную машину StarWind:

После этого в StarWind Management Console можно будет собрать RAID нужного вам уровня:

Рекомендации тут такие:

После этого в виртуальном модуле StarWind на полученном хранилище нужно будет создать VDO-устройство с нужными вам параметрами:

vdo create –activate=enabled –deduplication=enabled –compression=disabled –emulate512=enabled –indexMem=%size% –vdoLogicalSize=%size% –device=%yourdevice% -n=%name%

Здесь мы видим, что создается устройство с включенной дедупликацией, выключенной компрессией, нужным размером индексной памяти и заданного объема.

После создания это устройство надо отформатировать в XFS со следующими параметрами:

Далее вы можете создавать хранилище StarWind на этом устройстве и (опционально) сделать его реплику на партнерском узле в режиме HA. Также рекомендуется выставить настройку Disk.DiskMaxIOSize на хосте ESXi

В значение 512:

Ну и про оптимизацию производительности I/O-планировщика прочитайте вот эту статью базы знаний StarWind. Если вам интересен процесс создания хранилищ с дедупликацией и компрессией на базе StarWind Virtual SAN в стиле "от и до", то рекомендуем прочитать вот эту статью.

На днях в различных источниках появились сообщения об уязвимости CVE-2021-21972, которая есть в сервисах vCenter, что может привести к удаленному исполнению кода злоумышленником. Уязвимость по степени критичности оценивается на 9.8 из 10 (по шкале Common Vulnerability Scoring System Version 3.0) и имеет полное описание на сайте VMware как VMSA-2021-0002.

Интересно, что примеры реализации эксплоитов для Windows и Linux на базе этой уязвимости появились как минимум в шести разных местах, включая репозитории на GitHub (например, тут, тут и тут).

VMware сразу же выпустила патч к этой уязвимости, который вы можете загрузить по этой ссылке.

После публикации уязвимости начались массовые сканирования серверов vCenter (кстати, не удивительно, что уязвимость нашел русский инженер, вот ее описание):

Движок BinaryEdge нашел 15 000 серверов vCenter, торчащих в интернет с этой уязвимостью, а Shodan - около 6 700.

Уязвимость использует дырку в плагине vRealize Operations, который установлен по умолчанию, для неавторизованной загрузки файлов по порту 443, после чего становится доступным удаленное исполнение кода в операционной системе vCenter со всеми вытекающими.

В общем, всем нужно поскорее накатывать патч, так как любой с доступом к порту 443 сервера vCenter может потенциально получить к нему полный доступ.

Уязвимость CVE-2021-21972 затрагивает версии vCenter Server 6.5, 6.7 и 7.01. Соответственно, вам нужно накатить 6.5 Update 3n, 6.7 Update 3l или 7.0 Update 1c как можно скорее. Если накатить сейчас не можете, то временный workaround описан в KB 82374.

Команда PowerCLI компании VMware на днях выпустила обновление средства vSphere Desired State Configuration (DSC) версии 2.2. Механизм DSC есть в экосистеме Windows, начиная еще с Windows Server 2012 R2. С помощью него можно мониторить и управлять конфигурациями систем посредством специальных конфигурационных файлов на базе PowerShell, которые имплементируются через движок Local Configuration Manager (LCM), который должен быть на каждом хосте.

У VMware этот механизм работает несколько иначе, в качестве LCM используется прокси-хост, поскольку LCM не запустить ни на vCenter Server Appliance, ни на ESXi:

Так работал механизм до текущего момента, когда пользователям приходилось разворачивать отдельную Windows-машину под LCM. Но теперь появился модуль VMware.PSDesiredStateConfiguration, который предоставляет пользователям набор командлетов, чтобы скомпилировать и исполнить конфигурацию DCS без использования DSC Local Configuration Manager. Это позволяет использовать как Windows, так и Linux-машину в качестве прокси.

При этом пользователям по-прежнему предоставляется возможность использовать как vSphereDSC с движком PowerShell LCM, так и модуль VMware.PSDesiredStateConfiguration.

Давайте посмотрим, что нового появилось в DCS версии 2.2:

1. Новые ресурсы PowerCLI модуля

Вот они:

1. DatastoreCluster - создание, изменение, апдейт или удаление Datastore cluster
2. DatastoreClusterAddDatastore - добавление датастора к Datastore cluster
3. DRSRule - создание, изменение, апдейт или удаление правил DRS
4. VMHostVdsNic - изменение, апдейт или удаление "VMKernel nic" на vSphere Distributed switch
5. VMHostStorage - включение или отключение программного iSCSI-адаптера 
6. VMHostIScsiHbaVMKernelNic - используется для bind/unbind адаптеров VMKernel Network Adapters к указанному iSCSI Host Bus Adapter

2. Исправления ошибок

Поправлены ошибки в следующих командлетах:

• VMHostVDSwitchMigration 
• VMHostVssTeaming
• NfsDatastore

3. Операция Install/Update для модуля VMware vSphereDSC

Установка модуля теперь делается так:

Install-Module -Name VMware.vSphereDSC

Обновление вот так:

Update-Module -Name VMware.vSphereDSC

4. Новый модуль VMware.PSDesiredStateConfiguration

Как было сказано выше, теперь вы можете использовать Windows или Linux-машину без LCM для использования механизма DCS. Установить модуль можно следующей командой:

Install-Module -Name VMware.PSDesiredStateConfiguration

Новый командлет New-VmwDscConfiguration создает объект VmwDscConfiguration, который содержит информацию о конфигурации. Эту конфигурацию можно задать в ps1-файле и передать ее данному командлету. Например:

$config = New-VmwDscConfiguration -Path ./Site-A.ps1

Командлет Start-VmwDscConfiguration запускает исполнение конфигурации:

Start-VmwDscConfiguration -Configuration $config

Есть командлет Test-VmwDscConfiguration для проверки соответствия текущей конфигурации описанной:

Test-VmwDscConfiguration -Configuration $config

Можно также использовать параметр -Detailed для вывода полной информации по соответствию:

Test-VmwDscConfiguration -Configuration $config -Detailed

5. Новая динамическая конструкция vSphere Node

С помощью vSphere Node можно указать объект VINode (сервер vCenter или хост ESXi) и применить соответствующую конфигурацию к нужному узлу vSphere. Это дает следующие возможности:

• Персистентные сессии

Раньше для каждого подключения каждый ресурс требовал параметров учетной записи для установки сессии VISession. Теперь же если вы используете Vmware.PSDesiredStateConfiguration то можно создать персистентную VISession, которую можно использовать для всех ресурсов DCS.

• Не нужны файлы MOF

Поскольку LCM теперь не используется, то и для командлета New-VmwDSCconfiguration они не требуются. Конфигурация может храниться в переменной, либо в ps1-файле.

Скачать VMware vSphere DSC 2.2 можно по этой ссылке.

За последние дни на сайте проекта VMware Labs обновились некоторые полезные утилиты, а также были выпущены две новые - Workspace ONE Access Migration Tool и VCF Powernova.

Workspace ONE Access Migration Tool - это средство, которое позволяет упростить миграцию приложений от одного облачного клиента (tenant) к другому. Это может быть как в онпремизной, так и в SaaS-среде. Также это может быть полезно в целях отзеркаливания приложений одного тенанта к другому.

Возможности данной утилиты по миграции приложений:

• Копирование категорий приложений (App Categories)
• Миграция веблинков (сторонних IDO)
• Создание ссылок на федерированные (federated) приложения и копирование иконок (чтобы для пользователя ничего не менялось после миграции)
• Копирование App Assignment в раздел Category mapping

Скачать Workspace ONE Access Migration Tool можно по этой ссылке.

Вторая утилита - это средство VMware Cloud Foundation Powernova, которое позволяет проводить массовые операции по включению/выключению виртуальных машин по всему инвентарю виртуального датацентра VMware Cloud Foundation.

Утилита очень будет полезна в случае обслуживания инфраструктуры, а также при миграции VCF-окружений или необходимости отключить/подключить на время отдельные домены VCF.

Пока данное средство не работает для следующих окружений:

• Хосты vXRail
• Домены рабочей нагрузки WCP/Tanzu
• Вложенные (Nested) хосты ESXi

Скачать VMware Cloud Foundation Powernova можно по этой ссылке.

На сайте проекта VMware Labs появилась очередная полезная штука - Community Networking Driver for ESXi. Этот пакет представляет собой комплект нативных драйверов под ESXi для сетевых адаптеров, подключаемых в разъем PCIe.

Драйверы можно установить для VMware ESXi 7.0 или более поздних версий, а список поддерживаемых устройство выглядит так:

Установить драйвер можно с помощью команды:

esxcli software vib install -d /path/to/the offline bundle zip

После этого нужно обязательно перезагрузить ваш ESXi, до перезагрузки сетевой адаптер работать не будет.

Также если вы хотите использовать драйвер для Intel NUC 11, вам нужно будет встроить его в образ ESXi (Image Profile). Для этого можно использовать графический интерфейс Image Builder в vSphere Client, либо Image Builder CLI на базе PowerCLI.

Скачать пакет драйверов Community Networking Driver for ESXi можно по этой ссылке.

Компания VMware на днях выпустила обновленную версию инфраструктуры VMware Cloud Foundation (VCF) версии 4.2. Напомним, что это комплексное программное решение, которое включает в себя компоненты VMware vRealize Suite, VMware vSphere Integrated Containers, VMware Integrated OpenStack, VMware Horizon, NSX и другие, работающие в онпремизной, облачной или гибридной инфраструктуре предприятия под управлением SDDC Manager. О версии платформы VCF 4.1 мы писали вот тут.

Давайте посмотрим, что нового в VCF 4.2:

• Поддержка vSAN HCI Mesh Support - теперь VCF поддерживает технологию HCI Mesh в кластерах vSAN, позволяющую использовать емкости удаленных кластеров.
• Поддержка NSX-T Federation - теперь можно объединять несколько доменов рабочей нагрузки в одном представлении с помощью Global Manager.
• Статические IP-пулы для сетей NSX-T Host Overlay (TEP) - их можно использовать как альтернативу DHCP.
• Поддержка режима lockdown mode на хостах ESXi - их можно включать для доменов рабочей нагрузки через vCenter.
• Разное: VCF 4.2 включает в себя проверки валидации паролей, оптимизации производительности API, а также улучшения сообщений об ошибках ESXi.
• Интерфейс SDDC Manager включает в себя страницу Release Versions с информацией о новых возможностях продукта VCF, составе инфраструктуры и датах окончания поддержки.
• В интерфейсе SDDC Manager и через API можно фильтровать бандлы обновлений по целевым релизам, чтобы удобнее было обновляться только на нужные версии.
• Поддержка vRealize Automation для облачного аккаунта. Можно интегрировать SDDC Manager и домены рабочей нагрузки с VMware Cloud Assembly как облачными аккаунтами VCF (подробнее тут).
• Поддержка сервисных виртуальных машин с использованием образов vSphere Lifecycle Manager (vLCM). Это позволяет развернуть NSX-T Guest Introspection (GI) и NSX-T Service Insertion (SI) в доменах рабочей нагрузки с использованием vLCM.
• Обновлен список продуктов и их версий, входящих в инфраструктуру VCF (из главного - vRealize Suite 8.2, NSX-T 3.1 и последние версии vSphere и Horizon).

Полный список возможностей VMware Cloud Foundation 4.2 приведен в Release Notes. Есть также отдельный документ по версии для VxRail.

На днях компания VMware обновила свой главный документ, касающийся обеспечению безопасности виртуальных сред и самой платформы виртуализации - VMware vSphere 7 Security Configuration Guide. Напомним, что о его прошлой версии осенью прошлого года мы писали вот тут.

Давайте посмотрим, что появилось нового в обновленном SCG для vSphere 7, который традиционно состоит из PDF-файла описания и XLS-файла настроек, рекомендаций и пояснений:

• Исправлены ошибки в рекомендациях PowerCLI для аудита виртуальных машин.
• Добавлена вкладка "Deprecated" - там теперь будут те настройки, которые больше не актуальны. Что важно - там помечено, почему это случилось (в колонке Discussion).

• Настройка svga.vgaOnly перемещена в Deprecated. Она ограничивает ВМ на использование только VGA-разрешений, а многие современные ОС этого очень не любят (могут даже отключить отображение картинки в этом случае).
• Добавлены и обновлены рекомендации по отключению сервисных служб SLP и CIM на сервере ESXi. Эти протоколы часто не используются (их не используют и продукты VMware), поэтому лучше их отключить.
• Добавлены рекомендации по изоляции сети. Раньше как-то само собой подразумевалось, что нужно разделять сети управления, vMotion и vSAN, теперь же это формализовано в документе. Там же рекомендовано и физическое разделение сетей.
• Добавлена рекомендация по использованию только тех продуктов, старые версии которых еще официально поддерживаются со стороны VMware (например, вы можете выполнить все рекомендации и накатить все обновления, но использовать старый ESXi 5, что по понятным причинам небезопасно).
• Добавлено руководство по использованию модулей Trusted Platform Modules 2.0 (TPM).
• Снова возвращена рекомендация vm-7.pci-passthrough, касающаяся прямого доступа виртуальных машин к оборудованию, в частности шине PCIe.
• Добавлено руководство по отключению интерфейсов DCLI, если вы не используете его на vCenter Server. Также вам не нужно держать SSH постоянно открытым, так как в vSphere широкий и защищенный API, который вы можете использовать в разных фреймворках и утилитах.

Скачать VMware vSphere 7 Security Configuration Guide (как и руководства для других версий vSphere) можно по этой ссылке. Подробнее о документе также можно почитать тут.

Многие администраторы VMware vSphere знают, что для организации кластеров Windows Server Failover Clusters (WSFC) нужен эксклюзивный доступ к LUN, а значит на уровне виртуальной инфраструктуры подходили только RDM-диски. Ранее эти кластеры назывались MSCS, мы писали об их организации в виртуальной среде вот тут.

Такая ситуация была из-за того, что WSFC использует механизм резервация SCSI-3 Persistent Reservations, который координирует доступ к общему дисковому ресурсы. С другой стороны, VMFS использует собственный механизм блокировки LUN, поэтому команды WSFC перехватываются и отменяются, если используются диски VMDK. Поэтому RDM-устройства и использовались как средство маппинга дисков виртуальных машин к физическому устройству LUN.

Оказывается, ситуация поменялась с выпуском VMware vSphere 7, где появился механизм Clustered VMDK. Он позволяет командам SCSI3-PR выполняться и применяться к виртуальному диску VMDK, поэтому вам не нужен отдельный LUN.

К сожалению, все это работает только на хранилищах Fibre Channel.

Чтобы это начать использовать, на уровне датастора надо установить параметр "Clustered VMDK Supported":

Далее нужно понимать следующие условия и ограничения:

• Параметр кластера Windows Cluster "QuorumArbitrationTimeMax" должен быть выставлен в значение 60.
• LUN за этим датастором должен поддерживать команды ATS SCSI (как правило, это всегда поддерживается).
• LUN должен поддерживать резервации типа Write Exclusive All Resgistrants (WEAR).
• VMDK-диски должны быть типа Eager Zeroed Thick и виртуальные машины должны быть как минимум в режиме совместимости с vSphere.
• Не презентуйте LUN, которые используются как кластерные VMDK, для хостов ESXi версий ниже 7.0.
• Не комбинируйте датасторы для clustered и non-clustered VMDK на одном общем кластерном хранилище.
• Выделяйте один датастор на один кластер WSFC, не шарьте один датастор между несколькими инстансами кластеров WSFC.

Максимумы конфигураций для таких кластеров WSFC следующие:

Надо помнить еще о следующих ограничениях (более подробно тут):

• Конфигурация Cluster in a Box (CIB) не поддерживается. То есть надо настроить правила anti-affinity DRS Rules, чтобы разделить узлы кластера / виртуальные машины по разным хостам ESXi. Если вы попробуете такую ВМ с помощью vMotion переместить, то миграция завершится неудачно.
• Горячее расширение VMDK кластерной ВМ не поддерживается.
• Не поддерживается Storage vMotion и снапшоты.
• VMFS 5 и более ранние версии не поддерживаются.

Недавно появилась новость о том, что некое Ransomware использует уязвимости на хостах с гипервизором VMware ESXi для того, чтобы получить контроль над виртуальными машинами и зашифровать их диски VMDK, после чего злоумышленники просят выкуп у компаний за их расшифровку.

Речь идет об эксплуатации уязвимостей CVE-2019-5544 и CVE-2020-3992, касающихся недоработок протокола Service Location Protocol (SLP) и удаленного исполнения кода в ESXi и VMware Horizon DaaS (десктопы как услуга).

Про уязвимость CVE-2020-3992 мы писали вот тут, на данный момент она полностью пофикшена, но есть немало компаний, где политика обновлений оставляет желать лучшего, и где много непропатченных хостов ESXi используется в производственной среде.

Сообщается, что в атаке, которая произошла в прошлом году, группировка RansomExx (они же Defray777) смогла получить доступ к серверам ESXi инфраструктуры нескольких компаний и зашифровать диски виртуальных машин, которые были доступны этому ESXi. Информация об этом инциденте есть в ветке на Reddit.

По шагам атака выглядела так:

• Три пользователя в компании установили троян, который послали по почте.
• Атакующие получили привилегии, используя уязвимость CVE-2020-1472. На рабочих станциях стоял антивирус Касперского, который на тот момент не имел сигнатур этого трояна.
• Атакующие получили доступ к хостам, которые, в свою очередь, имели доступ к подсети управления ESXi, так как у злоумышленников были админские привилегии в AD.
• Без необходимости компрометации vCenter они просто запустили код на ESXi, используя две описанные выше уязвимости.
• Это привело к созданию скрипта на питоне, который шифровал диски VMDK. Вот тут приведено более детальное объяснение.

Избежать всего этого было просто - надо было вовремя пропатчить рабочие станции и серверы, ну и конечно не запускать трояны из письма:)

Администраторы VMware vSphere в больших инфраструктурах иногда используют кластеры Windows Server Failover Clusters (WSFC) на базе RDM-дисков, которые доступны для хостов VMware ESXi. Ранее они назывались Microsoft Cluster Service (MSCS). При использовании таких кластеров время загрузки хоста ESXi может вырасти аж до целого часа, если не поставить этим LUN статус Perennially reserved.

Суть проблемы в том, что WSFC ставит SCSI-3 reservations для своих LUN, используемых активным узлом, и если ESXi видит эти тома (то есть они не отмаскированы для него), то он безуспешно пытается получить к ним доступ. Для этого он делает несколько попыток при загрузке, пока не решает перейти к следующим томам. Статус этих операций вы можете увидеть, если нажмете Alt+F12 при загрузке хоста:

Xavier Avrillier написал статью о том, как с помощью esxicli/PowerCLI пометить такие тома как Perennially reserved, чтобы ESXi пропускал их при сканировании (об этом также рассказано в KB 1016106).

Сначала вам надо узнать LUN canonical name устройства. Делается это следующей командой PowerCLI:

PS> Get-VM MSCS-Node-1 | Get-HardDisk -DiskType RawPhysical | select scsicanonicalname
ScsiCanonicalName

  —————–

  naa.60001xxxxxxxxxxxxxxxxxxxxxxxacbc

  naa.60001xxxxxxxxxxxxxxxxxxxxxxxacbb

  naa.60001xxxxxxxxxxxxxxxxxxxxxxxacba

  naa.60001xxxxxxxxxxxxxxxxxxxxxxxacbd

  naa.60001xxxxxxxxxxxxxxxxxxxxxxxacb9

  naa.60001xxxxxxxxxxxxxxxxxxxxxxxacb8

Далее для нужного id-устройства устанавливается статус Perennially reserved через esxcli:

esxcli storage core device setconfig -d naa.id –perennially-reserved=true

Но удобнее это же сделать и через PowerCLI (ищем диски у машин по шаблону MSCS-Node-*):

PS> Set-PerenniallyReserved -PerenniallyReserved $True -VMHost (Get-VMHost) -HardDisk (Get-VM MSCS-Node-* | Get-HardDisk -DiskType RawPhysical)

Ну а для тех, кто хочет использовать vSphere Client, недавно появилась опция "Mark as Perennially Reserved" в разделе Storage Devices клиента:

Главное - не ошибитесь в выборе LUN, если вы отметите не то - это может привести к весьма печальным последствиям.

Источник.

Многие администраторы в крупных инфраструктурах сталкиваются с проблемами назначения и обновления лицензий компонентов VMware vSphere - серверов ESXi и vCenter. Это можно сделать в графическом интерфейсе vSphere Client, но когда у вас много хостов, это становится муторным делом, во время которого легко ошибиться или просто устать:) Давайте посмотрим, как можно просто это делать через PowerCLI...

Компания VMware опубликовала полезный FAQ, ссылка на который может в любой момент понадобиться администратору VMware vSphere для понимания различных аспектов системного хранилища серверов VMware ESXi.

Давайте посмотрим, на какие вопросы там можно найти ответы:

• Что изменилось в системном хранилище ESXi 7 по сравнению с прошлыми версиями? Мы об этом подробно писали тут.
• Что случится с разметкой системного хранилища при апгрейде на vSphere 7? Ответ тут и на этой картинке:

• Какое хранилище рекомендуется в качестве системного для ESXi?
• Что насчет устройств USB/SD? Можно ли использовать SD-карту для системного хранилища? (Спойлер: лучше не надо).
• Почему вы можете увидеть ситуацию, что хосты ESXi в "Degraded Mode"?
• Что вообще означает Degraded Mode?
• Можно ли добавлять локальное хранилище после апгрейда на ESXi 7? (Спойлер: да)
• Что делать, если хост в Degraded Mode, а хранилища вообще не видно? (Спойлер: смотреть External Syslog, NetDump Collector или Core Dump Partition)
• Если вы используете vSphere AutoDeploy, то как работает развертывание системного хранилища? Подробнее об этом вот тут

Это статья нашего спонсора - сервис-провайдера ИТ-ГРАД, предоставляющего в аренду виртуальные машины из облака по модели IaaS.

Виртуализация оборудования, также известная как серверная виртуализация, представляет собой абстракцию вычислительных ресурсов от программного обеспечения, которое использует эти ресурсы. В статье поговорим об истоках виртуализации и остановимся на ее аппаратной реализации.

В традиционной физической вычислительной среде ПО, такое как операционные системы или корпоративные приложения, имеет прямой доступ к базовому компьютерному оборудованию и компонентам, включая процессор, память, хранилище, некоторые чипсеты драйверы ОС. Ранее это создавало серьезные проблемы в настройке программного обеспечения, а также существенно затрудняло перемещение или переустановку приложений на другое оборудование — например при восстановлении из резервных копий после аварии.

Об истоках виртуализации

Термин «виртуализация» был придуман в конце 1960-х - начале 1970-х годов в ходе исследовательских проектов IBM и MIT в области совместного использования вычислительных ресурсов группами пользователей. Подробнее об этом вы можете почитать в нашем блоге на Хабре: [ССЫЛКИ на IBM/360 и истоки виртуализации].

В настоящее время виртуализация широко распространена в ИТ. В сфере облачных сервисов лидируют продукты компаний VMware, Microsoft, Citrix и Oracle.

Как работает аппаратная виртуализация

Процесс аппаратной виртуализации включает в себя установку гипервизора или диспетчера виртуальных машин (VMM). Именно они создают уровень абстракции между программным обеспечением и непосредственным «железом». После установки гипервизора программное обеспечение полагается на виртуальные представления вычислительных компонентов — то есть, к примеру, на виртуальные CPU вместо физических. К наиболее популярным гипервизорам можно отнести решения VMware vSphere на основе ESXi и Microsoft Hyper-V.

Виртуализированные вычислительные ресурсы объединяются в изолированные «группы», называемые виртуальными машинами (ВМ). На подготовленную ВМ можно установить операционную системы, а затем требуемые приложения. Виртуализированные системы могут иметь сразу несколько виртуальных машин одновременно, при этом каждая виртуальная машина логически изолирована от своих «соседей». Таким образом, если одна из ВМ подвергнется атаке вируса, будет перегружена или взломана, это никак не скажется на других машинах внутри системы.

Виртуализация позволяет бизнесу сократить издержки, связанные с приобретением серверного оборудования. К примеру, вместо покупки 10 разных серверов для размещения 10 приложений, каждому из которых для работы требуется отдельная ОС, достаточно построить виртуализированную систему, которая будет содержать требуемое количество ВМ, в рамках всего одного достаточно мощного сервера.

Традиционная архитектура в сравнении с виртуальной
https://searchservervirtualization.techtarget.com/definition/hardware-virtualization

Поскольку гипервизор устанавливается непосредственно на сервер, а операционные системы и ПО добавляются позже, такой подход часто называют виртуализацией «на голом железе». В последние годы гипервизоры стали самостоятельными узко заточенными ОС. Есть и альтернативный подход, работающий в случае, если вы не можете/не желаете работать с «голым железом» — сперва устанавливается главная операционная система, а уже в ней разворачивается гипервизор и все ВМ. Этот метод часто называют виртуализацией с хост-системой. Сейчас он чаще всего используется для виртуализации контейнеров.

Типы аппаратной виртуализации

Существует несколько типов аппаратной виртуализации. Среди них — полная виртуализация, паравиртуализация и виртуализация с аппаратной поддержкой. Кратко поговорим о каждом из них.

Полная виртуализация полностью имитирует требуемое оборудование для гостевой операционной системы. В итоге получается среда, аналогичная ОС, работающей на отдельном сервере. Использование полной виртуализации позволяет администраторам запускать виртуальные среды любых конфигураций без каких-либо дополнительных аппаратных ухищрений.

Паравиртуализацией называется подход, при котором на ВМ запускается особым образом подготовленная (измененная и/или перекомпилированная) версия гостевой ОС. Иными словами, системные администраторы должны соблюдать исходные требования ОС к железу лишь частично.

Виртуализация с аппаратной поддержкой использует аппаратное обеспечение компьютера в качестве «архитектурной поддержки» для создания полностью виртуализированной ВМ и управления ею. Виртуализация с аппаратной поддержкой была впервые представлена ??IBM в 1972 году с IBM System / 370. Виртуализация с аппаратной поддержкой на сегодняшний день является наиболее распространенной формой виртуализации.

Технология виртуализации дала жизнь популярным сейчас облачным сервисам, таким как:

• виртуальные VDS/VPS-серверы;
• IaaS, инфраструктура как услуга;
• терминальные серверы в облаке;
• VDI, виртуальная инфраструктура рабочих столов;
• cloud gaming и многим другим.

Многие администраторы VMware vSAN задаются вопросом - а сколько прослужат диски в кластере хранилищ? Сегодня для vSAN уже имеет смысл использовать только SSD-диски, так как их стоимость уже вполне стала приемлемой для построения All-Flash хранилищ.

Как известно, в кластере vSAN есть 2 типа дисков - Cache (кэширование данных перед записью на постоянное хранение) и Capacity (постоянное хранилище). В первом случае, конечно же, использование ресурса диска идет в разы быстрее, чем для Capacity Tier.

Florian Grehl в своем блоге провел замер использования дисков обоих ярусов в плане записанных гигабайт в сутки в тестовой лаборатории. Вы сами сможете сделать это с помощью его PowerCLI-сценария, а также визуализовав данные в Graphite.

У него получилась вот такая картина:

В день у него получилось:

• 300 ГБ на диски Caching tier
• 20 ГБ на диски Capacity tier

Надо понимать, что объем записанных данных на каждый диск зависит от числа дисков в группе, а также развернутого типа RAID и политики FTT.

Когда вы покупаете SSD-диск, гарантия на него идет как на машину: время (обычно 5 лет), либо пробег (а в случае с диском это "TBW" = Terabytes Written, то есть записанный объем в ТБ) - в зависимости от того, что наступит раньше.

Как правило, для Capacity tier ресурс TBW за 5 лет на практике выработать не получится, а вот для Caching tier неплохо бы этот параметр замерить и сопоставить с характеристиками дисков. Например, 300 ГБ в день дает 535 ТБ за 5 лет.

Ну а вот параметры TBW, например, для устройств Samsung:

Как видно из таблицы, некоторые устройства могут прослужить вам значительно меньше 5 лет, в зависимости от интенсивности использования в вашей инфраструктуре и модели устройства.

Интересно, что продукты VMware vSphere и VMware vSAN имеют разные списки совместимости оборудования (HCL - Hardware Compatibility Lists). Ronald de Jong в своем блоге описал ситуацию, когда у него драйвер SCSI-контроллера подошел для vSphere, но не подошел для vSAN.

После установки обновления драйвера для VMware vSphere через VMware Lifecycle Manager он получил вот такие ворнинги для vSAN в vSphere Client:

Драйвер smartpqi (70.4000.0.100-4vmw.701.0.0.17325551) уже подходит для vSphere, но еще не провалидирован для решения vSAN. В этом можно убедиться в списке совместимости для vSAN по этой ссылке, где есть только старый драйвер (3vmw):

Если же заглянуть в список совместимости для vSphere, то там будет обозначена поддержка старого и нового драйверов:

Таким образом, нужно провести даунгрейд драйвера, чтобы он подходил и для vSphere, и для vSAN. Сначала идем на Patch Portal и находим там нужное обновление в виде VIB-пакета:

Вот этот драйвер:

После загрузки в консоли ESXi запускаем установщик VIB-пакета командой:

esxcli software vib install -d /vmfs/volumes/vsanDatastore/tmp/VMware-ESXi-7.0U1-16850804-depot.zip -n=smartpqi

После этого все ворнинги по совместимости драйвера исчезнут:

Но в Lifecycle Manager все еще будут висеть предупреждения о необходимости поставить последнюю версию драйвера и проапдейтить ESXi:

Некоторое время назад мы писали об улучшении технологии горячей миграции vMotion (тут и тут) в последней версии VMware vSphere 7 Update 1. Сегодня мы вкратце расскажем о вариантах переноса рабочих нагрузок в кластер хранилищ VMware vSAN на базе вот этой заметки.

Первое, что вы должны решить - это в каком рабочем процессе вы будете мигрировать виртуальные машины с помощью vMotion: за один шаг (хранилище+сервер) или за два (сначала сервер, потом хранилище).

1. Миграция в два шага (Two-Step Migrations)

При выборе миграции виртуальной машины у нас есть опция изменения либо сервера ESXi машины, либо ее хранилища, либо и того, и другого:

• Change compute resource only - это первый шаг миграции для случая, когда не-vSAN хранилище может быть презентовано существующему кластеру vSAN. Также это может быть востребовано в рамках топологии VMware vSAN HCI Mesh, где хранилище монтируется удаленному кластеру vSAN.
• Change storage only - это второй шаг миграции, когда машина на хосте ESXi уже находится в кластере vSAN, и мы выполняем перенос ее VMDK уже на собственные хранилища кластера.

Надо сказать, что миграция машин в два шага имеет бОльшую гранулярность, что позволит вам получить промежуточный результат и зафиксировать результат в середине (например, смигрированная на другой хост, но не хранилище машина), что может сэкономить время при повторной попытке миграции в случае каких-то проблем.

2. Миграция в один шаг

Этот способ миграции реализуется, когда вы выбираете опцию Change both compute resource and storage или Cross vCenter Server export. Надо понимать, что процесс этот весьма затратный, и выбирать этот вариант можно, когда у вас есть большой запас по ресурсам и времени для вычислительных ресурсов и ресурсов хранилищ. Ну или когда вы не можете расшарить хранилище между двумя разными кластерами vSphere / vSAN.

Удобство это способа еще и в том, что если у вас есть много времени на миграцию, то можно просто поставить vMotion для нужных нагрузок, и все будет постепенно переезжать без участия администратора.

Также для переноса нагрузок между разными инфраструктурами есть опция Cross vCenter Server export. В обновлении VMware vSphere 7 Update 1c главным нововведением стала интеграция функций миграции Advanced Cross vCenter Server vMotion Capability (ранее это был виртуальный модуль Cross vCenter Workload Migration Utility) в интерфейс vSphere Client. Оно же называется XVM.

Эта функциональность используется для переноса виртуальных машин средствами Cross vCenter vMotion между виртуальными датацентрами под управлением разных серверов vCenter (поддерживаются как единый SSO-домен, так и разные). При этом не требуется настроенного механизма Enhanced Linked Mode (ELM) или Hybrid Linked Mode (HLM) для серверов vCenter в разных датацентрах.

Если вы решили сделать пакетную миграцию виртуальных машин в vSphere Client, то нужно для кластера или пула ресурсов перейти на вкладку VMs и с шифтом выбрать группу ВМ для миграции, после чего из контекстного меню выбрать Migrate...:

Надо сказать, что машины одной группы можно мигрировать только в одинаковом состоянии (Powered on или Powered off), поэтому удобно отсортировать их по колонке State.

Ну и в заключение - картинка об улучшении технологии vMotion с момента ее появления в 2003 году:

Не все администраторы VMware vSphere и vSAN знают, что в версии vSAN 6.7 Update 3 появилась утилита vsantop, которая по аналогии с esxtop, используемой для получения метрик с хостов ESXi, позволяет получать метрики с устройств и хранилищ vSAN.

Запускается утилита просто: vsantop

По умолчанию она отображает метрики для сущности host-domclient. Чтобы выбрать нужную вам сущность - устройства, хост или кластер, нужно нажать большую клавишу <E> с шифтом:

После того, как вы выберете нужную сущность, будут отображаться метрики для нее с дефолтными колонками в данной категории. Чтобы выбрать колонки, нужно нажать клавишу <f>:

Для отображения можно выбрать только 10 полей, если хотите добавить какое-то поле, то какое-то из текущих придется убрать.

Также esxtop может работать в пакетном режиме с заданным интервалом и записывать метрики в CSV-файл:

vsantop -b -d [delay] -n [iterations] > [file location & name]

usage: vsantop [-h] [-v] [-b] [-d delay] [-n iterations]
    -h prints this help menu.
    -v prints version.
    -b enables batch mode.
    -d sets the delay between updates in seconds.
    -n runs vsantop for only n iterations. Use "-n infinity" to run forever.

Например, вот такая команда запустит сбор метрик с 10-секундным интервалом, всего будет 20 таких итераций, а результаты будут записаны в файл CSV:

vsantop -b -d 10 -n 20 > /vmfs/volumes/vsanDatastore/vsantop/result.csv

Многие администраторы решения для создания отказоустойчивых хранилищ VMware vSAN иногда задумываются, чем отличаются политики хранилищ виртуальных машин (Storage Policies) для растянутых кластеров в плане Disaster Tolerance.

Дункан Эппинг написал об этом полезную заметку. Если вы не хотите, чтобы ваша виртуальная машина участвовала в растянутом кластере, то вам следует выбрать один из двух вариантов для настройки Site Disaster Tolerance: хранить все данные на основном сайте или все на резервном:

• None – Keep data on preferred (stretched cluster)
• None – Keep data on non-preferred (stretched cluster)

Между тем, в интерфейсе есть несколько схожих вариантов:

Например, есть еще два, казалось бы, подходящих:

• None – Stretched Cluster
• None – Standard Cluster

Но оба этих варианта политик хранилищ для растянутых кластеров не подходят. В первом случае (None – Stretched Cluster) виртуальная машина будет обрабатываться на уровне дисковых объектов, и vSAN будет решать, куда их поместить в растянутом кластере. Вполне может получиться такая ситуация, что один VMDK находится на одной площадке, а второй - на другой. При этом сама машина же может исполняться только на одном ESXi:

Такая ситуация очевидно очень плоха с точки зрения производительности.

Во втором же случае (None – Standard Cluster), если ваша машина настроена с точки зрения хранилищ на RAID-1 и FTT=1, то в растянутом кластере это превращается в SFTT=0 (Stretched FTT), что означает, что данные с одной площадки будут зеркалироваться на другую, но на уровне одной площадки будет храниться только одна копия данных дисковых объектов, что плохо с точки зрения надежности и отказоустойчивости.

Поэтому в растянутых кластерах для машин, которым не нужна "растянутость", используйте настройки Keep data on preferred или Keep data on non-preferred.

Решение для виртуализации сетей VMware NSX-T, в отличие от его vSphere-версии NSX-V, не имеет графического интерфейса для настройки отсылки логов на серверы Syslog.

Graham Smith написал краткую заметку о настройке Syslog для решения VMware NSX-T, включая NSX-T Manager, узлы Edge Nodes и серверы ESXi.

Самый удобный вариант - это использовать в качестве Syslog-сервера решение VMware Log Insight. Сначала заходим по SSH на NSX-T Manager и выполняем там следующую команду, указав IP-адрес сервера Log Insight:

MulNSXT01> set logging-server 192.168.10.8 proto udp level info 
        WARNING - You are configuring udp-based log forwarding. This will send sensitive information unencrypted over the network. The Splunk App for NSX-T only accepts TLS connections.

На узлах Edge Nodes также нужно выполнить такую же команду, зайдя по SSH:

DCA-MulNSXT-ESG01> set logging-server 192.168.10.8 proto udp level info
        WARNING - You are configuring udp-based log forwarding. This will send sensitive information unencrypted over the network. The Splunk App for NSX-T only accepts TLS connections.

На серверах ESXi процесс выглядит несколько иначе. Нужно выполнить вот такую последовательность команд:

[root@DCA-MulComp01:~] esxcli network firewall ruleset set -r syslog -e true
[root@DCA-MulComp01:~] esxcli system syslog config set --loghost=udp://192.168.10.8:514
[root@DCA-MulComp01:~] esxcli system syslog reload
[root@DCA-MulComp01:~] esxcli system syslog mark -s "This is a test message"

Первая команда разрешает в фаерволе трафик Syslog, вторая - настраивает сервер адрес сервера, третья - подхватывает настройки, ну а четвертая - отсылает тестовое сообщение, чтобы можно было проверить работоспособность механизма Syslog со стороны Log Insight.

Там это тестовое сообщение можно увидеть в разделе Events:

Чтобы проверить логирование на стороне фаервола, можно создать простое правило с тестовым тэгом:

Далее в Log Insight можно увидеть это событие, поискав по этому тегу:

Чтобы проверить конфигурацию Syslog на стороне сервера ESXi, нужно выполнить следующую команду:

[root@DCA-MulComp01:~] esxcli system syslog config get
   Check Certificate Revocation: false
   Default Network Retry Timeout: 180
   Dropped Log File Rotation Size: 100
   Dropped Log File Rotations: 10
   Enforce SSLCertificates: true
   Local Log Output: /scratch/log
   Local Log Output Is Configured: false
   Local Log Output Is Persistent: true
   Local Logging Default Rotation Size: 1024
   Local Logging Default Rotations: 8
   Log To Unique Subdirectory: false
   Message Queue Drop Mark: 90
   Remote Host: udp://192.168.10.8:514
   Strict X509Compliance: false

На стороне NSX-T Manager и на узлах Edge Nodes конфигурацию Syslog можно проверить такой командой:

DCA-MulNSXT-ESG01> get logging-servers 
Mon Dec 28 2020 UTC 17:37:16.600
192.168.10.8:514 proto udp level info

Многие администраторы виртуальной инфраструктуры VMware vSphere при планировании апгрейда не выясняют важных моментов, касающихся совместимости продуктов и так называемых upgrade paths, то есть поддерживаемых производителем рабочих процессов обновления платформы. В этой статье мы расскажем о том, что нужно выяснить перед апгрейдом...

На днях компания VMware выпустила обновление VMware vSphere 7 Update 1c, в котором появилось довольно много всего нового для минорного апдейта.

Давайте посмотрим, что именно:

• Статистики по физическим сетевым адаптерам - добавилось 5 новых параметров (dropRx, dropTx, errorsRx, RxCRCErrors и errorsTx), которые позволяют вам обнаружить сетевые ошибки и предпринять действия по исправлению ситуации.
• Параллельное обновление хостов в кластерах, которые находятся под управлением vSphere Lifecycle Manager. Теперь хосты ESXi под управлением vLCM можно одновременно перевести в режим обслуживания и начать их обновление.
• Advanced Cross vCenter vMotion - это функциональность виртуального модуля Cross vCenter Workload Migration Utility, который был предназначен для переноса виртуальных машин средствами Cross vCenter vMotion между виртуальными датацентрами под управлением разных серверов vCenter (поддерживаются как единый SSO-домен, так и разные). Теперь эта штука интегрирована в vSphere Client, где удобно работать с миграциями ВМ между датацентрами (поддерживается и пакетная миграция нескольких ВМ):

• Можно подключать сторонние плагины для управления сервисами на платформе vSAN Data Persistence из vSphere Client таким же способом, как вы управляете сервером vCenter.
• Улучшения vSAN DOM scrubber (проверка блоков, к которым давно не было обращений).
• Улучшения Supervisor Cluster:
  • Изоляция пространств имен (Supervisor Namespace Isolation) за счет выделенного маршрутизатора T1 Router (кластеры в сети NSX-T используют для этого новую топологию).
  • Поддержка NSX-T 3.1 для Supervisor Clusters
  • Удалена поддержка Supervisor Cluster версий 1.16.x.
• Улучшения служб Tanzu Kubernetes Grid for vSphere:
  • Поддержка HTTP/HTTPS Proxy – вновь созданные кластеры Tanzu Kubernetes могут использовать глобальные прокси HTTP/HTTPS для исходящего трафика, а также скачивать образы контейнеров из интернет-репозиториев.
  • Вновь созданные кластеры Tanzu Kubernetes из коробки интегрированы со службой vSphere Registry Service. Также с этой службой будут интегрированы кластеры, обновленные до новой версии.
  • Кластеры Tanzu Kubernetes теперь могут монтировать дополнительные тома к виртуальным машинам, что позволяет увеличивать дисковую емкость узлов. Это дает возможность пользователям развертывать большие образы контейнеров, которые больше дефолтного размера в 16 ГБ.

Скачать VMware vSphere 7 Update 1c можно по этой ссылке. Release Notes доступны тут.

Какое-то время назад мы писали о полезном документе "Product Lifecycle Matrix", в котором приведены основные моменты касающиеся жизненного цикла продуктов VMware: дата доступности продукта для загрузки, окончание поддержки, завершение технического сопровождения и дата снятия с продаж.

Наш читатель Ser указал на интересный ресурс - это онлайн-тул Product Lifecycle Matrix, который выводит актуальную информацию из указанного документа в возможностью сортировки и фильтрации по нужным колонкам:

Удобно, что в таблице можно не только искать нужный продукт (кстати, не ищите vSphere, потому что там продукты разделяются на ESXi и vCenter), но и экспортировать полученный табличный вид в PDF или CSV, а также вывести его на печать.

Красным отмечены даты у продуктов, для которых поддержка или техническое сопровождение заканчивается в ближайшие 6 месяцев, а фиолетовым - те, у которых поддержка уже закончилась. Обратите внимание, что также есть отдельная вкладка для неподдерживаемых и устаревших продуктов.

В общем, нужная штука - пользуйтесь.

На днях на сайте проекта VMware Labs появилось очередное интересное обновление - новая версия гипервизора VMware ESXi Arm Edition 1.2 для процессоров ARM (на их базе построена, например, архитектура Raspberry Pi, а также многие IoT-устройства).

Напомним, что о версии ESXi Arm Edition 1.1 мы писали вот тут, а здесь также рассказывали об установке этого гипервизора на платформу Raspberry Pi.

Давайте посмотрим, что нового в VMware ESXi Arm Edition 1.2:

• Если у хоста нет датасторов, то datastore browsing отключен
• Пофикшен отсутствующий параметр context_id для вызовов CPU_ON
• Исправлена проблема с контроллером GICv2 (теперь SGI всегда включены и работают как устройства GIC-500)
• Поддержка гостевых ОС на базе big-endian
• Убраны требования/ограничения на initrd для ВМ без UEFI

В целом, все это технические фиксы - но обновить вашу тестовую лабу не помешает. Новая версия ESXi Arm встает только как свежая установка, обновление прошлых версий не поддерживается. Можно сохранить прошлые тома VMFS, выбрав опцию "Preserve VMFS", но машины надо будет перерегистрировать заново.

Скачать ESXi Arm Edition 1.2 можно по этой ссылке.

Недавно у компании VMware появился интересный документ "Performance Characterization of NVMe-oF in vSphere 7.0 U1", в котором рассказывается о производительности протокола NVMe-oF (NVMe over Fibre Channel).

Напомним, что NVMe-oF - это реализация технологии RDMA, которая позволяет не использовать CPU для удаленного доступа к памяти и пропускать к хранилищу основной поток управляющих команд и команд доступа к данным напрямую, минуя процессоры серверов и ядро операционной системы. Еще один его плюс - это то, что он обратно совместим с такими технологиями, как InfiniBand, RoCE и iWARP. Для всего этого нужна поддержка RDMA со стороны HBA-адаптера хоста ESXi.

Поддержка NVMe-oF для доступа к хранилищам появилась еще в VMware vSphere 7, а в обновлении Update 1 была улучшена и оптимизирована. В указанном выше документе рассматривается сравнение производительности традиционного протокола Fibre Channel Protocol (SCSI FCP) с реализацией FC-NVMe в vSphere 7.0 U1.

Для всех бенчмарков использовался тот же HBA-адаптер и инфраструктура сети хранения данных SAN. Для генерации нагрузки использовались утилиты fio (для создания разных по размеру операций ввода-вывода I/O, а также паттернов нагрузки) и Microsoft CDB (бенчмарк для генерации OLTP-нагрузки в SQL Server).

Результат оказался весьма интересным. С точки зрения IOPS протокол NVMe-oF смог выжать почти в два раза больше операций ввода-вывода практически для IO любого размера:

Задержка (Latency) также снизилась практически в два раза:

На картинке ниже приведены результаты теста Microsoft CDB для базы данных в числе транзакций в секунду:

Здесь также виден значительный прирост для NVMe-oF, а для двух виртуальных машин производительность выше почти в раза!

Остальные интересные детали тестирования - в документе.

Многие администраторы уже используют продукт VMware vSAN 7 Update 1 для создания отказоустойчивых кластеров хранилищ на базе серверов ESXi. Некоторое время назад мы писали про технологию Cloud Native Storage (CNS), которая позволяет по запросу развертывать и обслуживать хранилища для виртуальных машин, содержащих внутри себя контейнеры. По-сути, это платформа для управления жизненным циклом хранения для контейнеризованных приложений.

Давайте посмотрим, что нового появилось в возможностях CNS в обновлении vSAN 7 U1:

1. Расширение томов PersistentVolumeClaim

В Kubernetes v1.11 появились функции расширения томов за счет изменения объекта PersistentVolumeClaim (пока только офлайн). Помните, что уменьшение тома (shrink) не поддерживается.

2. Статический провижининг в Supervisor Cluster

Эта возможность позволяет презентовать существующий том в кластере K8s, который будет интегрирован с vSphere Hypervisor Cluster (он же Supervisor Cluster, vSphere with K8s, Project Pacific).

3. Поддержка vVols для vSphere K8s и TKG Service

Теперь обеспечивается поддержка внешних хранилищ на базе vK8s и TKG с использованием томов vVols.

4. Функции Data Protection for Modern Applications

В vSphere 7.0 U1 появились функции поддержки резервного копирования Dell PowerProtect и Velero для Pacific Supervisor и TKG кластеров. Для Velero вы можете инициировать создание снапшотов через Velero plugin и хранить их в облаке S3.

5. Функции vSAN Direct

Возможность vSAN Direct позволяет использовать Direct Attach Storage (обычно на базе физических HDD-дисков) для хранения виртуальных машин VMware vSphere.

Вы можете создавать vSAN Direct Datastores, которые не являются общими для кластера датасторами, но физические диски таких хранилищ можно, например, напрямую подключать к виртуальным модулям (Virtual Appliances) или к контейнерам, исполняемым в среде vSphere, которым нужно объектное хранилище, но при этом хочется использовать его напрямую, минуя стандартный путь данных vSAN.

Мы уже много писали о новых возможностях платформы виртуализации VMware vSphere 7 Update 1. Сегодня мы посмотрим подробнее, что нового появилось в плане механики резервного копирования виртуальных машин (Data Protection), реализуемой через VMware vStorage API for Data Protection.

1. Функции Network QoS для трафика резервного копирования

Теперь возможности приоритезации трафика Network QoS доступны и для трафика резервного копирования виртуальных машин. Настроить это можно в vSphere Client в разделе System Traffic > Configure > Edit:

Основное назначение данной настройки - дать возможность урезать полосу канала резервного копирования таким образом, чтобы это не влияло существенным образом на трафик производственной среды.

2. Улучшенная обработка задач резервного копирования

Теперь при входе хоста ESXi в режим обслуживания во время резервного копирования есть флаг Entering Maintenance Mode (EMM), что означает, что операции бэкапа должны переключиться на другой хост ESXi, где сессия NFC (network file copy) может быть продолжена. Это автоматическое переключение происходит прозрачно для задачи резервного копирования, но требует от ПО для бэкапа поддержки данного флага, чтобы обнаружить момент переключения.

3.Улучшенное масштабирование для одновременно запущенных задач РК

Для окружений, где параллельно запущено множество задач резервного копирования, ограничения сервера vCenter могут стать проблемой. Использование сервиса VPXA не позволяет кастомизировать буфер памяти для задач, обрабатываемых через vCenter. В апдейте vCenter Server 7.0 U1 теперь можно настраивать буфер памяти, чтобы обрабатывать множество потоков резервного копирования. Например, для 50 одновременных бэкапов нужно использовать 96 MБ памяти.

4. Улучшения vSphere APIs for I/O Filtering (VAIO)

Фреймворк VAIO - это основной интерфейс для партнерских решений, которые могут перехватывать запросы ввода-вывода операционной системы к виртуальному диску. В этом случае команда ввода-вывода (I/O) не будет применена к диску без прохождения через IO Filter, созданный сторонним ПО.

Теперь здесь появились следующие улучшения:

• CIM provider теперь стал 64-битным
• Сами VAIO-фильтры теперь будут распространяться как компоненты, а не VIB-пакеты

Напомним, что в vSphere 7 появилась концепция компонентов вместо отдельных VIB-пакетов. В vSphere 7 компоненты - это набор VIB-пакетов, которые может использовать Lifecycle Manager, чтобы накатывать патчи. Теперь компоненты можно накатывать через esxcli с использованием команды component apply.